Sans routage dynamique, chaque routeur ne connaît que ses réseaux directement connectés. PC-A peut joindre Serv-B via la route par défaut de RtA, mais il lui est impossible d'atteindre Serv-E car RtB ne possède aucune route vers le réseau 172.12.0.0/24 derrière RtE. Les routeurs de liaison ignorent également tous les réseaux derrière NAT.

• PC-A → Serv-B (172.11.0.1) ✅ — fonctionne via la route par défaut RtA → RtB
• PC-A → Serv-E (172.12.0.1) ❌ — RtB ne connaît pas le réseau 172.12.0.0/24
• PC-A → RtF (20.0.0.1) ❌ — le cœur de réseau ne route pas encore vers RtF
• PC-A ↔ PC-F1/F2 🚫 — impossible : adresses privées masquées par NAT des deux côtés
• RtC → RtB ✅ / RtC → RtF ❌ — routeurs limités à leurs voisins directs

La commande show ip nat translations sur RtA confirme que l'adresse Inside Local 192.168.0.1 (PC-A) est traduite en Inside Global 20.6.6.2 (interface série de RtA) lors d'un ping vers Serv-B. La capture du PDU en mode simulation valide la translation visuellement : l'adresse source passe de 192.168.0.1 (Inbound) à 20.6.6.2 (Outbound).

• RtA# show ip nat translations → Inside Local 192.168.0.1 → Inside Global 20.6.6.2
• Mode simulation Packet Tracer → inspection du PDU ICMP Inbound vs Outbound

Les routeurs de liaison (RtB, RtC, RtD, RtE) ne s'échangent aucune information de routage. Il faut activer OSPF sur chacun d'eux et déclarer tous leurs réseaux pour qu'ils construisent une vision complète de la topologie et calculent les meilleures routes.

Activation du processus OSPF 1 sur les quatre routeurs de liaison. Les interfaces LAN de RtB (vers Serv-B) et de RtE (vers Serv-E) sont placées en passive-interface pour ne pas envoyer de hello OSPF inutilement vers les serveurs.

• RtB (router-id 2.2.2.2) : 5 réseaux déclarés en area 0 · passive-interface Se0/1/1
• RtC (router-id 3.3.3.3) : réseaux 20.5.5.0 et 20.1.1.0 en area 0
• RtD (router-id 4.4.4.4) : réseaux 20.4.4.0 et 20.3.3.0 en area 0
• RtE (router-id 5.5.5.5) : 5 réseaux déclarés en area 0 · passive-interface Se0/0/0
• Masques inversés : /30 → wildcard 0.0.0.3 · /24 → wildcard 0.0.0.255

La table de routage de RtB affiche des routes marquées « O » — apprises dynamiquement par OSPF. La notation [110/192] indique la distance administrative (110) et la métrique (coût calculé). RtB connaît désormais le réseau 172.12.0.0/24 de Serv-E qu'il ignorait avant.

Pour le réseau 20.0.0.0/30 (Site F), la table affiche deux sauts de coût identique — via 20.5.5.1 (RtC) et via 20.4.4.1 (RtD). OSPF effectue un équilibrage de charge automatique entre les deux chemins redondants.

• Saut 1 — 192.168.0.254 : passerelle RtA (LAN Site A)
• Saut 2 — 20.6.6.1 : RtB (Siège) via liaison série
• Saut 3 — 20.4.4.1 : RtC (Agence Nord)
• Saut 4 — 20.3.3.1 : RtE (Agence Est)
• Saut 5 — 172.12.0.1 : Serv-E ✅ — destination atteinte

J'ai désactivé l'interface Serial0/0/1 de RtB (lien vers RtC) via shutdown pour simuler une coupure sur le lien redondant. L'objectif est de prouver qu'OSPF reconverge automatiquement sans aucune intervention humaine.

• Message console immédiat : %OSPF-5-ADJCHG: Nbr 3.3.3.3 on Serial0/0/1 from FULL to DOWN
• show ip ospf neighbor : le voisin 3.3.3.3 (RtC) a disparu, seul 4.4.4.4 (RtD) reste actif
• Table de routage mise à jour en temps réel : toutes les routes via 20.5.5.1 ont disparu
• Réseau 172.12.0.0/24 désormais atteint uniquement via RtD (20.4.4.1) · coût [110/129]
• Connectivité vers tous les sites distants maintenue sans interruption

J'ai abaissé la bande passante de Serial0/0/1 de RtB à 256 Kbps via bandwidth 256. Contrairement à RIP qui compte les sauts, OSPF utilise la formule Coût = 10⁸ / Bande passante — la qualité du lien impacte donc directement le choix de la route.

• Coût du lien 256 Kbps : 10⁸ / 256 000 ≈ 390 (contre 64 pour 1544 Kbps)
• Chemin via RtC devient trop cher (coût total > 450) vs chemin via RtD (coût 129 = 64+64+1)
• OSPF recalcule et redirige automatiquement le trafic vers RtD

• Saut 1 — 192.168.0.254 : RtA
• Saut 2 — 20.6.6.1 : RtB
• Saut 3 — 20.4.4.1 : RtD ← changement ici, évite la liaison lente
• Saut 4 — 20.1.1.1 : RtE
• Saut 5 — 20.0.0.1 : RtF ✅

Le Site A ne dispose que d'un seul routeur (RtA). En cas de panne, tous les postes du site perdent leur accès réseau. Pour garantir la continuité de service, un second routeur doit être ajouté avec un chemin alternatif vers le cœur de réseau.

Ajout du routeur RtA-bis avec deux interfaces : LAN FastEthernet 0/0 à 192.168.0.253/24 reliée au switch (port Fa0/2), et WAN Serial 0/0/0 à 20.7.7.2/30 pour la liaison série vers RtD. Intégration dans OSPF (router-id 1.1.1.2, passive-interface Fa0/0).

• Ajouter RtA-bis dans la maquette Packet Tracer, câbler au switch et à RtD
• Configurer Fa0/0 : ip address 192.168.0.253 255.255.255.0 / no shutdown
• Configurer Se0/0/0 : ip address 20.7.7.2 255.255.255.252 / no shutdown
• Activer OSPF : router ospf 1 · router-id 1.1.1.2 · networks 192.168.0.0 et 20.7.7.0 · passive-interface Fa0/0

J'ai activé l'interface Serial0/0/0 de RtD (adresse 20.7.7.1/30) et ajouté le réseau 20.7.7.0/30 dans son processus OSPF. RtD annonce ce nouveau chemin au reste de la maquette. En configurant temporairement PC-A avec la passerelle 192.168.0.253, un tracert vers 172.12.0.1 confirme le nouveau trajet.

• Saut 1 — 192.168.0.253 : RtA-bis (nouveau chemin)
• Saut 2 — 20.7.7.1 : RtD via liaison série
• Saut 3 — 20.3.3.1 : RtE
• Saut 4 — 172.12.0.1 : Serv-E ✅

Avoir deux routeurs ne suffit pas si les postes doivent changer manuellement de passerelle en cas de panne. HSRP permet de présenter une adresse IP virtuelle unique aux hôtes — le basculement devient alors totalement transparent pour les utilisateurs.

RtA est configuré comme routeur Actif avec une priorité de 150 (supérieure au défaut de 100). RtA-bis reste en mode Standby avec la priorité par défaut. Les deux partagent l'IP virtuelle 192.168.0.254 que les postes utilisent comme passerelle.

• RtA — standby 1 ip 192.168.0.254 · standby 1 priority 150 · standby 1 preempt → état Active
• RtA-bis — standby 1 ip 192.168.0.254 · standby 1 preempt (priorité 100 par défaut) → état Standby
• Validation : show standby brief sur chaque routeur confirme les états

PC-A est configuré avec la passerelle virtuelle 192.168.0.254. Un tracert vers 172.12.0.1 montre que le premier saut passe par l'IP physique de RtA (192.168.0.252), confirmant que HSRP dirige bien le trafic vers le routeur prioritaire. Le flux suit ensuite le chemin OSPF classique vers le cœur de réseau.

• Saut 1 — 192.168.0.252 : RtA (routeur Actif HSRP répond à l'ARP)
• Saut 2 — 20.6.6.1 : RtB (Siège)
• Saut 3 — 20.4.4.1 : RtD
• Saut 4 — 20.3.3.1 : RtE · Saut 5 — 172.12.0.1 : Serv-E ✅

J'ai désactivé l'interface LAN de RtA (shutdown sur Fa0/1) pour simuler une panne du routeur principal. Le basculement HSRP se produit immédiatement et de façon transparente pour PC-A qui conserve sa passerelle virtuelle .254.

• Sur RtA : %HSRP-6-STATECHANGE: Fa0/1 Grp 1 state Active → Init
• Sur RtA-bis : %HSRP-6-STATECHANGE: Fa0/0 Grp 1 state Standby → Active

• Saut 1 — 192.168.0.253 : RtA-bis prend le relai automatiquement
• Saut 2 — 20.7.7.1 : RtD via la liaison série de RtA-bis
• Saut 3 — 20.3.3.1 : RtE · Saut 4 — 172.12.0.1 : Serv-E ✅
• Connectivité maintenue sans aucune intervention sur PC-A